Some service providers use conventional risk-based authentication systems to assess a risk of processing customer transactions. For example, an online bank may employ a risk engine of such a risk-based authentication system to assign risk scores to banking transactions where higher risk scores indicate higher risk.
In generating a risk score, the risk score engine can take as input values of various transaction attributes (e.g., geolocation). For each user, there is an associated history based on values of the attributes associated with previous transactions involving that user. The risk engine incorporates the history associated with the user into an evaluation of the risk score. Significant variation of one or more attribute values from those in the user's history may signify that the transaction has a high risk.
It will be understood that in some approaches the velocity of the user between transactions can be used as the input to determine the risk of the user. For example, a user cannot be in two distant places at the same time. Hence, whenever an input of the user location is received, it is used together with the former reported location to estimate the user's velocity. If the velocity of the user between the two transactions is too high, it may be that one of the locations is associated with an attacker trying to impersonate the user and a high risk score is generated.
Unfortunately, there are deficiencies with the above approaches to determining risk. For example, the problem with using the velocity of the user as an input to determine risk is that in many cases the location associated with the user is not correct. It may be the case that the location is estimated correctly but is not the user location leading to wrong velocity estimation and false alarms. For example, a user may connect remotely to a mobile network and log in through a VPN connection resulting in the user location being indicated as the location of the network provider even though the user may be anywhere in the globe. In another case, a user can have two devices, each reporting distant locations such as a mobile IP-geolocation reporting Boston while a PC reports London.
The present invention aims to overcome at least some of the above problems associated with prior risk-based authentication systems.